Synchronization of digital content rendering is a primary consideration not only for co-located client devices but also for remotely located client devices. For example, consider a sports bar having multiple televisions that are viewable at any one time. A person viewing these televisions simultaneously may quickly become lost as to “what is going on” when shown different parts of a sporting event, even if just a few seconds off. Accordingly, lack of synchronization between these televisions may become distracting to the point of removing the benefit of including the multiple televisions.
This consideration even exists in situations in which the client devices are remotely located from each other. For example, social media and other communication techniques enable users to communicate and comment in real time with each other as events occur. In a home viewing example, if viewers are sharing reactions on social media, live digital content that is significantly out of sync may cause some viewers to spoil exciting plot developments, or otherwise lose assumed shared context for the program. Accordingly, a lack of synchronization in rendering by remote devices may cause a lack of synchronization in these communications, which may quickly become frustrating to these viewers.
As viewers expect and have experienced close synchronization with conventional broadcast television, viewers also want a similar experience with Internet streaming media. In conventional broadcast television, multiple television receivers receive the same broadcast signal simultaneously and display the transmitted video immediately. Accordingly, the presentations are inherently in sync. However, conventional live HTTP streaming media techniques are typically out of sync by up to two or more segment durations, where segments are typically six to ten seconds in length.
In one conventional HTTP streaming example, live playback begins at a number of segments behind the most recently posted segment according to a manifest file. The number of segments “behind” depends on the timing of the acquisition of a manifest file and when a new revision and new segment is posted as well as time taken to select, obtain, and render the new segment. Accordingly, it has been observed that client devices may be out of sync by up to two segments based on differences in this timing, e.g., anywhere from six to twelve seconds. In another example, local “wall-clock” times are specified in a manifest file to indicate a time at which a segment is to be rendered. However, this approach requires the clocks on each of the client devices to be synchronized, one to another, which is not typically the case. Other proprietary techniques have also been developed to determine “what time it is” in order to render an appropriate segment of content. These proprietary techniques, however, typically require inclusion of additional software and hardware resources (e.g., network synchronization) which are typically not be available on each client device.